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The identity of an operating system running on a computer 
is determined from an identity associated with an initial 
component for the operating system, combined with iden- 
tities of additional components that are loaded afterwards. 
Loading of a digital rights management operating system on 
a subscriber computer is guaranteed by validating digital 
signatures on each component to be loaded and by deter- 
mining a trust level for each component. A trusted identity 
is assumed by the digital rights management operating 
system when only components with valid signatures and a 
pre -determined trust level are loaded. Otherwise, the oper- 
ating system is associated with an untrusted identity. Both 
the trusted and untrusted identities are derived from the 
components that were loaded. Additionally, a record of the 
loading of each component is placed into a boot log that is 
protected from tampering through a chain of public -private 
key pairs. 

31 Claims, 10 Drawing Sheets 




04/16/2004, EAST Version: 1.4.1 



US 6,327,652 Bl 

Page 2 



U.S. PATENT DOCUMENTS 

6,073,124 6/2000 Krishnan ct al. . 

6,112,181 8/2000 Shear et al. . 

6,138,119 10/2000 Hall et al. . 

6,148,402 11/2000 Campbell, 

6,157,721 12/2000 Shear et al. . 

6,185,683 2/2001 Ginter et at. . 

OTHER PUBLICATIONS 

Murphy et al., "Preventing Pirvacy: Authorization Software 
May Ease Hollywood's Fear of the Net", Internet World 
Magazine, Apr. 1, 2000, 3 pages. 

"Internet Security: SanDisk Products and New Microsoft 
Technology Provide Copy Protected Music for Internet 
Music Player Market. (Product Announcement)", Edge: 
Work Group Computing Report, Apr. 19, 1999, 2 pages. 



Arbaugh et al., "A Secure and Reliable Bootstrap Architec- 
ture", Distributed Systems Laboratory, Philadelphia, PA, 
1997, pp. 65-71. 

Lampson et al., "Authentication in Distributed Systems: 
Theory and Practice", Digital Equipment Corporation, ACM 
Transactions on Computer Systems, vol. 10, No. 4, Nov. 
1992, PP 265-310. 

Clark et al., "Bits: A Smartcard Protected Operation Sys- 
tem", Communications of the ACM, vol. 37, No. 11, Nov. 
1994, pp. 66-70, 94. 

Yee, "Using Secure Coprocessors", School of Computer 
Science, Camegie Mellon University, 1994, 104 pages. 

* cited by examiner 



04/16/2004, EAST version: 1.4.1 



U.S. Patent Dec. 4, 2001 



Sheet 1 of 10 



US 6,327,652 Bl 




04/16/2004, EAST Version: 1.4.1 



U.S. Patent 



Dec. 4, 2001 Sheet 2 of 10 



US 6,327,652 Bl 



160 
162 

164 

166 
168 

170 



144 



148 



140 



Suscriber Unit 124 





CPU 



Processor 



Cryptography 
Accelerator 



Key Pair 
(K cpu ,K cpu 1 ) 



Mfr. Certificate 



S/W ID 



Boot Stack 



Reg. ) 

3 




Volatile Memory 




Sound System 



142 



Nonvolatile 
Memory 

Operating 
System 



Boot Block 



Secure Storage 

S/W 
Program(s) 




c 



Key 





J o 



Network Interface 



Display 



180 
182 

184 



186 
188 



146 



r 

150 



04/16/2004, EAST Version: 1.4.1 



U.S. Patent Dec. 4, 2001 Sheet 3 of 10 US 6,327,652 Bl 




04/16/2004, EAST Version: 1.4.1 



U.S. Patent 



Dec. 4, 2001 



Sheet 4 of 10 



US 6,327,652 Bl 



EXEC 
BO 
LOA 


;ute 

OT 
DER 






' r 


CHECK 
COMPONENT 
SIGNATURE 



301 



303 



■305 




RENOUNCE 
TRUSTED 
IDENTITY 



307 



CHECK TRUST 
LEVEL 



L<JRUSTED?J> 
Y 



r 



311 



LOAD 
COMPONENT 




"COMPLETE? 



313 
N 



r 



315 



ASSUME 
IDENTITY 



<^PNP?^^^ 



04/16/2004, EAST Version: 1.4.1 



U.S. Patent Dec 4, 2001 Sheet 5 of 10 US 6,327,652 Bl 



400- 



403 



405 



407 



401 



NAME 



VERSION 



SIGNER 



600 



[BOOT BLOCK] 




V 1 


[COMPONENTS] 


k 2 




[COMPONENTS] 


k 3 


k 2 





[COMPONENTS] 




k 1 


[ 0 ] | k N* 1 





04/16/2004, EAST Version: 1.4.1 



U.S. Patent Dec 4, 2001 Sheet 6 of 10 



US 6,327,652 Bl 



501 



GET 1ST KEY 
PAIR 



503 



LOAD & 
RECORD BOOT 
BLOCK 



515 



LOAD & 
RECORD 
COMPONENTS 



505 



GET NEW KEY 
PAIR 



507 



RECORD NEW 
PUBLIC KEY IN 
LOG 



-509 



SIGN LOG WITH 
PREV. PRIVATE 
KEY 



•511 



DELETE 
PREVIOUS 
PRIVATE KEY 




513 



519 



CREATE 
SENTINEL & 
DEL. KEYS 



-^EXIT^ 



^c^. 5 



04/16/2004, EAST Version: 1.4.1 



U.S. Patent Dec. 4, 2001 Sheet 7 of 10 



US 6,327,652 Bl 



701 



703 



705 



2l 



700 

U BOOT CODE 



SIGN. 



PUB. 
KEY 



?<^. 7/4 



r 



711 



710 < 



713 



BASIC BOOT CODE ^ 


PUB. 719 
KEY 


SIGN. 223. 


BOOT CODE 717 


PUB. 721 
KEY 


SIGN. ^ 



111 ^-729 



COMPONENT 



SIGN. 



730 



^-731 ^-733 



BOOT CODE 



PUB. 
KEY 



735 



737 



r 



739 



COMPONENT 



SIGN. 



CERT. 



04/16/2004, EAST Version: 1.4.1 



U.S. Patent Dec 4, 2001 



Sheet 8 of 10 



US 6,327,652 Bl 




04/16/2004, EAST Version: 1.4.1 



U.S. Patent Dec 4, 2001 Sheet 9 of 10 US 6,327,652 Bl 



900 



901 
906 



STANDARD 
DIGITAL 
CERTIFICATE 
FIELDS 



907 



905 



905 



PROPERTYI 



PROPERTYI 



ARGUMENTSI 



ARGUMENTS2 



9 



04/16/2004, EAST Version: 1.4.1 



U.S. Patent 



Dec 4, 2001 Sheet 10 of 10 US 6,327,652 Bl 



1000 




BASIC TRUST LEVEL ID 
EXTENDED TRUST LEVEL ID1 
EXTENDED TRUST LEVEL ID2 



1100 




1001 
1003 
1003 



1101 USAGE COUNTER 

1103 DERIVATION RIGHTS 

1 1 05 EXPIRATION COUNTER 

1107 SUBLICENSE RIGHTS 



04/16/2004, EAST Version: 1.4.1 



US 6,327,652 Bl 

1 2 

LOADING AND IDENTIFYING A DIGITAL without permission. A publisher could also adjust pricing 

RIGHTS MANAGEMENT OPERATING according to whether the client is allowed to make a per- 

SYSTEM sistent copy, or is just allowed to view the content online as 

it is delivered. These scenarios reveal a peculiar arrange- 

RELATED APPLICATIONS 5 ment. The user that possesses the digital bits often does not 

have full rights to their use; instead, the provider retains at 

This application is a continuation-in-part of U.S. provi- i east some of the rights. In a very real sense, the legitimate 

sional patent application Ser. No. 60/105,891 filed on Oct. user of a computer can be an adversary of the data or content 

26, 1998, which is herein incorporated by reference, and is provider. 

related to co-pending and co-filed applications titled "Sys- JQ "Digital rights management*' is therefore fast becoming a 

tern and Method for Authenticating an Operating System to central requirement if online commerce is to continue its 

a Central Processing Unit, Providing the CPU/OS with rapid growth. Content providers and the computer industry 

Secure Storage, and Authenticating the CPU/OS to a Third must quickly provide technologies and protocols for ensur- 

Party" (Ser. No. 09/266,207, filed Mar. 10, 1999, "Key- ing that digital content is properly handled in accordance 

based Secure Storage" (Ser. No. 09/227,568, filed Jan, 8, 15 with the rights granted by the publisher. If measures are not 

1999, Digital Rights Management Using One Or More taken, traditional content providers may be put out of 

Access Predicates, Rights 1999, and "Digital Rights Man- business by widespread theft, or, more likely, will refuse 

ager Certificates, And Licenses" (Ser. No. 09/227,559, filed altogether to deliver content online. 

Jan. 8, 1999). Traditional security systems ill serve this problem. There 

20 are highly secure schemes for encrypting data on networks, 

FIELD OF THE INVENTION authenticating users, revoking certificates, and storing data 

This invention relates generally to computer operating securel y* Unfortunately, none of these systems address the 

systems, and more particularly to booting and identifying an assurance of content security after it has been delivered to a 

operating system that enforces digital rights. chent ' s machine. Traditional uses of smart cards offer little 

25 help. Smart cards merely provide authentication, storage, 

COPYRIGHT NOTICE/PERMISSION am * encryption capabilities. Ultimately, useful content must 

be assembled within the host machine for display, and again, 

A portion of the disclosure of this patent document at ^ point the bits ^ su bject to theft. Cryptographic 

contains material which is subject to copyright protection. coprocessors provide higher-performance cryptographic 

The copyright owner has no objection to the facsimile operations, and are usually programmable but again, 

reproduction by anyone of the patent document or the patent 30 fundamentally, any operating system or sufficiently privi- 

disclosure as it appears in the Patent and Trademark Office i cgcc i application, trusted or not, can use the services of the 

patent file or records, but otherwise reserves all copyright cryptographic processor. 

rights whatsoever. The following notice applies to the soft- There appear tQ be lhree solutions t0 mis pro blem. One 

ware and data as descnbed below and in the drawings solution is to do away with gen eral-purpose computing 

hereto: Copyright © 1998, Microsoft Corporation, All devices and ^ spe cial-purpose tamper-resistant boxes for 

Rights Reserved. delivery, storage, and display of secure content. This is the 

BACKGROUND OF THE INVENTION *PP roach **** b y lhe ""e industry and their set-top 

boxes, and looks set to be the model for DVD-video 

More and more content is being delivered in digital form, 40 presentation. The second solution is to use secret, propri- 

and more and more digital content is being delivered online etary data formats and applications software, or to use 

over private and public networks, such as Intranets, the tamper-resistant software containers, in the hope that the 

Internet and cable TV networks. For a client, digital form resulting complexity will substantially impede piracy. The 

allows more sophisticated content, while online delivery third solution is to modify the general-purpose computer to 

improves timeliness and convenience. For a publisher, digi- 45 support a general model of client-side content security and 

tal content also reduces delivery costs. Unfortunately, these digital rights management. 

worthwhile attributes are often outweighed in the minds of This invention is directed to a system and methodology 
publishers by the corresponding disadvantage that online that falls generally into the third category of solutions, 
information delivery makes it relatively easy to obtain a fundamental building block for client-side content 
pristine digital content and to pirate the content at the 50 security is a secure operating system. If a computer can be 
expense and harm of the publisher. booted only into an operating system that itself honors 
Piracy of digital content, especially online digital content, content rights, and allows only compliant applications to 
is not yet a great problem. Most premium content that is access rights-restricted data, then data integrity within the 
available on the Web is of low value, and therefore casual machine can be assured. This stepping-stone to a secure 
and organized pirates do not yet see an attractive business 55 operating system is sometimes called "Secure Boot." If 
stealing and reselling content. Increasingly, though, higher- secure boot cannot be assured, then whatever rights man- 
value content is becoming available. Books and audio agement system the secure OS provides, the computer can 
recordings are available now, and as bandwidths increase, always be booted into an insecure operating system as a step 
video content will start to appear. With the increase in value to compromise it. 

of online digital content, the attractiveness of organized and 6Q Secure boot of an operating system is usually a multi- 
casual theft increases. stage process. A securely booted computer runs a trusted 
The unusual property of digital content is that the pub- program at startup. The trusted program loads an initial layer 
lisher (or reseller) gives or sells the content to a client, but of the operating system and checks its integrity (by using a 
continues to restrict rights to use the content even after the code signature or by other means) before allowing it to run. 
content is under the sole physical control of the client. For 65 This layer will in turn load and check the succeeding layers, 
instance, a publisher will typically retain copyright to a work This proceeds all the way to loading trusted (signed) device 
so that the client cannot reproduce or publish the work drivers, and finally the trusted applications). 
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An article by B. Lampson, M. Abadi, and M. Burrows, The identity of an operating system running on a corn- 
entitled "Authentication in Distributed Systems: Theory and puter is determined from an identity associated with an 
Practice/' ACM Transactions on Computer Systems vlO, initial component for the operating system, combined with 
265, 1992, describes in general terms the requirements for identities of additional components that are loaded after- 
securely booting an operating system. The only hardware 5 wards. Loading of a digital rights management operating 
assist is a register that holds a machine secret. When boot system on a subscriber computer is guaranteed by validating 
begins this register becomes readable, and there's a hard- ^gilal signatures on each component to be loaded and by 
ware operation to make this secret unreadable Once it's dctcrmining a trust level for each co mv0Dtnl A trusted 
unreadable, it stays unreadable until the next boot. The boot identi fc heW b me d - ^ ^ ement u 

Ir J,^ It io system 'when only components tith vahd Signatures and a 

operating system can use to authenticate itself to other ' . . j * 4 1 i i jj • ^ 

parties in order to establish trust. We note that in this P«-determmcd trust level are loaded. Otherwise, the oper- 

scheme, a malicious user can easily subvert security by « associated with an untrusted identity. Both 

replacing the boot code. tne trus * e " m( * tintrusted identities are denved from the 

dark and Hoffman's BITS system is designed to support components that were loaded, 

secure boot from a smart card. P. C. Clark and L. J.Hoffman, 35 The initial component is described variously as a boot 

"BITS: A Smartcard Operating System/' Comm. ACM. 37, block, or a set of components required to boot the operating 

66, 1994. In their design, the smart card holds the boot system. 

sector, and PCs are designed to boot from the smart card. [ n another aspect of the invention, a record of the loading 

The smart card continues to be involved in the boot process of cach component is placed into a boot log. The boot log is 

(for example, the smart card holds the signatures or keys of 20 protected from tampering through a chain of public-private 

other parts of the OS). kcy paifS ^ contents of the boot log are used to determine 

Bennet Yee describes a scheme in which a secure proces- whether the operating system ^ t0 be considered trusted or 

sor first gets control of the booting machine. B. Yee, "Using entrusted 

Secure Coprocessors", Ph.D. Thesis, Carnegie Mellon ri ' . , • i - . 
University, 1994. The secure processor can check code 25 Use of a special pubhe-pnvate key pair to validate a boot 
integrity before loading other systems. One of the nice block and to alleviate ^placement issues should a standard 
features of this scheme is that there is a tamper-resistant ke y P air be compromised is also disclosed, 
device that can later be queried for the details of the running The guaranteed loading of a digital lights management 
operating system. operating system on a general-purpose personal computer 
Another secure boot model, known as AEGIS, is dis- 30 ensures that downloaded content can be protected from 
closed by W. Arbaugh, D. G. Farber, and J. M Smith in a unauthorized access. Furthermore, the generation of an 
paper entitled "A Secure and Reliable Bootstrap identity for an operating system based on its loaded corn- 
Architecture", Univ. of Penn. Dept. of CIS Technical Report, ponents allows a content provider to knowledgeably deter- 
IEEE Symposium on Security and Privacy, page 65, 1997. mine whether to trust content to the subscriber computer. 
This AEGIS model requires a tamper-resistant BIOS that has 35 The present invention describes systems, clients, servers, 
hard-wired into it the signature of the following stage. This methods, and computer-readable media of varying scope. In 
scheme has the very considerable advantage that it works addition to the aspects and advantages of the present inven- 
well with current microprocessors and the current PC tion described in this summary, further aspects and advan- 
architecture, but has three drawbacks. First, the set of trusted tages of the invention will become apparent by reference to 
operating systems or trusted pub Ushers must be wired into 40 the drawings and by reading the detailed description that 
the BIOS. Second, if the content is valuable enough (for follows, 
instance, e-cash or Hollywood videos), users will find a way 

of replacing the BIOS with one that permits an insecure BRIEF DESCRIPTION OF THE DRAWINGS 

boot. Third, when obtaining data from a network server, the nir , -, A • ,- „ r 4 > , ^ 

' r • % ... FIG 1A is a diagram of the hardware and operating 

client has no way of proving to the remote server that it .s 45 enviromnen , jn conjllncti(ra ^ « exemplary embodi- 

mdeed runnmg a trusted system. men|s of ^ mv ^ m be pract i ced; 

On the more general subject of client-side rights riT _ c A c . A , 
management, several systems exist or have been proposed to \ 1B 1S JV^m of a client computer for use with 
encapsulate data and rights in a tamper-resistant software exem P lar y embodiments of the invention; 
package. An early example is IBM's Cryptolope. Another 50 FIG. 2 is a diagram illustrating a system-level overview of 
existent commercial implementation of a rights management an exemplary embodiment of the invention; 
system has been developed by Intertrust. In the audio FIG. 3 is a flowchart of a method to be performed by a 
domain, AT&T Research have proposed their "A2b" audio client when booting or loading system components accord- 
rights management system based on the PolicyMaker rights ing to an exemplary embodiment of the invention; 
management system. 55 pj G 4 ^ a diagram of a certificate revocation list data 

Therefore, there is a need in the art for guaranteeing that structure for use in an exemplary implementation of the 

a digital rights management operating system has been invention; 

properly loaded on a computer. Furthermore, such a digital p IG 5 ^ a flowchart of a method to be performed by a 

rights management operating system must be readily dis- cueo t to create a boot log according to an exemplary 

cernable from a non-trusted operating system executing on 60 embodiment of the invention; 

the same computer. FIG. 6 is a block diagram of an exemplary boot log 

SUMMARY OF THE INVENTION created using the method of FIG. 5; 

The above-mentioned shortcomings, disadvantages and FIGS. 7 A, 7B and 7C are block diagrams of boot blocks 

problems are addressed by the present invention, which will 65 for use in an exemplary embodiment of the invention; 

be understood by reading and studying the following sped- FIG. 8 is a block diagram of key generation functions 

fication. according to an exemplary embodiment of the invention; 
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FIG. 9 is a diagram of a rights manager certificate data 
structure for use in an exemplary implementation of the 
invention; 

FIG. 10 is a diagram of a required properties access 
control list data structure for use in an exemplary imple- 
mentation of the invention; and 

FIG. 11 is a diagram of a license data structure for use in 
an exemplary implementation of the invention. 

DETAILED DESCRIPTION OF THE 
INVENTION 

In the following detailed description of exemplary 
embodiments of the invention, reference is made to the 
accompanying drawings, which form a part hereof, and in 
which is shown by way of illustration specific exemplary 
embodiments in which the invention may be practiced. 
These embodiments are described in sufficient detail to 
enable those skilled in the art to practice the invention, and 
it is to be understood that other embodiments may be utilized 
and that logical, mechanical, electrical and other changes 
may be made without departing from the spirit or scope of 
the present invention. The following detailed description is, 
therefore, not to be taken in a limiting sense, and the scope 
of the present invention is defined only by the appended 
claims. 

The detailed description is divided into four sections. In 
the first section, the hardware and the operating environment 
in conjunction with which embodiments of the invention 
may be practiced are described. In the second section, a 
system level overview of the invention is presented. The 
third section described methods and data structures 
employed by various exemplary embodiments of the inven- 
tion. Finally, in the fourth section, a conclusion of the 
detailed description is provided. 

Hardware and Operating Environment 

FIG. 1A is a diagram of the hardware and operating 
environment in conjunction with which embodiments of the 
invention may be practiced. The description of FIG. 1A is 
intended to provide a brief, general description of suitable 
computer hardware and a suitable computing environment in 
conjunction with which the invention may be implemented. 
Although not required, the invention is described in the 
general context of computer-executable instructions, such as 
program modules, being executed by a computer, such as a 
personal computer. Generally, program modules include 
routines, programs, objects, components, data structures, 
etc. that perform particular tasks or implement particular 
abstract data types. 

Moreover, those skilled in the art will appreciate that the 
invention may be practiced with other computer system 
configurations, including hand-held devices, multiprocessor 
systems, microprocessor-based or programmable consumer 
electronics, network PCs, minicomputers, mainframe 
computers, and the like. The invention may also be practiced 
in distributed computing environments where tasks are 
performed by remote processing devices that are linked 
through a communications network. In a distributed com- 
puting environment, program modules may be located in 
both local and remote memory storage devices. 

The exemplary hardware and operating environment of 
FIG. 1A for implementing the invention includes a general 
purpose computing device in the form of a computer 20, 
including a processing unit 21, a system memory 22, and a 
system bus 23 that operatively couples various system 
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components, including the system memory 22, to the pro- 
cessing unit 21. There may be only one or there may be more 
than one processing unit 21, such that the processor of 
computer 20 comprises a single central-processing unit 

5 (CPU), or a plurality of processing units, commonly referred 
to as a parallel processing environment. The computer may 
be a conventional computer, a distributed computer, or any 
other type of computer; the invention is not so limited. 
The system bus 23 may be any of several types of bus 

10 structures including a memory bus or memory controller, a 
peripheral bus, and a local bus using any of a variety of bus 
architectures. The system memory may also be referred to as 
simply the memory, and includes read only memory (ROM) 
24 and random access memory (RAM) 25. A basic input/ 

15 output system (BIOS) 26, containing the basic routines that 
help to transfer information between elements within the 
computer 20, such as during start-up, is stored in ROM 24. 
The computer 20 further includes a hard disk drive 27 for 
reading from and writing to a hard disk, not shown, a 

20 magnetic disk drive 28 for reading from or writing to a 
removable magnetic disk 29, and an optical disk drive 30 for 
reading from or writing to a removable optical disk 31 such 
as a CD ROM or other optical media. 
The hard disk drive 27, magnetic disk drive 28, and 

25 optical disk drive 30 are connected to the system bus 23 by 
a hard disk drive interface 32, a magnetic disk drive inter- 
face 33, and an optical disk drive interface 34, respectively. 
The drives and their associated computer-readable media 
provide nonvolatile storage of computer-readable 

30 instructions, data structures, program modules and other 
data for the computer 20. It should be appreciated by those 
skilled in the art that any type of computer-readable media 
that can store data that is accessible by a computer, such as 
magnetic cassettes, flash memory cards, digital video disks, 

35 Bernoulli cartridges, random access memories (RAMs), 
read only memories (ROMs), and the like, may be used in 
the exemplary operating environment. 

A number of program modules may be stored on the hard 
disk, magnetic disk 29, optical disk 31, ROM 24, or RAM 

40 25, including an operating system 35, one or more applica- 
tion programs 36, other program modules 37, and program 
data 38. A user may enter commands and information into 
the personal computer 20 through input devices such as a 
keyboard 40 and pointing device 42. Other input devices 

45 (not shown) may include a microphone, joystick, game pad, 
satellite dish, scanner, or the like. These and other input 
devices are often connected to the processing unit 21 
through a serial port interface 46 that is coupled to the 
system bus, but may be connected by other interfaces, such 

50 as a parallel port, game port, or a universal serial bus (USB). 
A monitor 47 or other type of display device is also 
connected to the system bus 23 via an interface, such as a 
video adapter 48. In addition to the monitor, computers 
typically include other peripheral output devices (not 

55 shown), such as speakers and printers. 

The computer 20 may operate in a networked environ- 
ment using logical connections to one or more remote 
computers, such as remote computer 49. These logical 
connections are achieved by a communication device 

60 coupled to or a part of the computer 20; the invention is not 
limited to a particular type of communications device. The 
remote computer 49 may be another computer, a server, a 
router, a network PC, a client, a peer device or other 
common network node, and typically includes many or all of 

65 the elements described above relative to the computer 20, 
although only a memory storage device 50 has been illus- 
trated in FIG. 1. The logical connections depicted in FIG. 1 
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include a local-area network (LAN) 51 and a wide -area the private key "Kc^" 1 " In this way, only the CPU knows 

network (WAN) 52. Such networking environments are the CPU private key KcpcT 1 ; the same key is not issued to 

commonplace in offices, enterprise-wide computer other CPUs and the manufacturer keeps no record of it. The 

networks, intranets and the Internet. certificate can in principle be stored on a separate physical 

When used in a LAN-networking environment, the com- s device associated with the processor but still logically 

puter 20 is connected to the local network 51 through a belongs to the processor with the corresponding key. 

network interface or adapter 53, which is one type of The manufacturer has a pair of public and private signing 

communications device. When used in a WAN-networking keys, ¥^ MFR and K^^ -1 . The private key K^^ -1 is known 

environment, the computer 20 typically includes a modem only to the manufacturer, while the public key K MFR is made 

54, a type of communications device, or any other type of 10 available to the public. The manufacturer certificate 166 

communications device for establishing communications contains the manufacturer's public key K^^^ the CPU's 

over the wide area network 52, such as the Internet. The public key and the above testimony. The manufacture 

modem 54, which may be internal or external, is connected signs the certificate using its private signing key, Km^' 1 , as 

to the system bus 23 via the serial port interface 46. In a follows: 

networked environment, program modules depicted relative « Mfr Ccrtificate= ^ c^s-for-Boot, K CPU \ signed by 

to the personal computer 20, or portions thereof, may be k^*, -1 
stored in the remote memory storage device. It is appreciated 

thatthenctworkconnectionsshownarccxemplary andother J he P 1 """". cert,fies-for-boot is a pledge : by the mairo- 

means of and communications devices for establishing a factur f r lhat « created *f CPU ™ d CPU *X P» r 

communications link between the computers may be used. M «wK*ng to a known speculation The pledge further states 

_ . , . ... that the CPU can correctly perform authenticated boot 

The hardware and operating environment in conjunction jures, as are described below in more detail . The 

witt i which embodiments of the invention may be practiced mamlfactlirer certificate 166 is publicly accessible, yet it 

has been described The computer in conjunction with which cannQt fce f ^ wimom of the manufacturer . s 

embodiments of the invention may be practiced may be a private kev K -1 

conventional computer, a distributed computer, or any other 25 The cpu $™ has m imemal softwafe idemi ^ 

type of computer; the invention is not so limited. Such a (SJR) m which ^ idcnti of an authenticatcd 

computer typically includes one or more processing units as K ^ tem 180 or a predetermined false value (e.g., 

its processor, and a computer-readable medium such as a zero) . f ^ cpTJ dctermincs that tflC ati tcm 180 

memory. Tlie computer may also include a communications cannQt be autnenticated> ^ operating syslem (OS) 180 is 

device such as a network adapter or a modem, so that it is stofed - n ^ m U2 md Qn ^ cpTJ 14Q ^ 

able to communicatively couple to other computers. operating system 180 has a block of code 182 that is used to 

One exemplary embodiment of a suitable client computer authenticate the operating system to the CPU during the boot 

is described in the related application titled "System and operation. The boot block 182 uniquely determines the 

Method for Authenticating an Operating System to a Central 35 operating system, or class of operating systems (e.g. those 

Processing Unit, Providing the CPU/OS with Secure signed by the same manufacturer). The boot block 182 can 

Storage, and Authenticating the CPU/OS to a Third Party," also be signed by tne os manufacturer, 
and illustrated in FIG. IB as subscriber unit 124. The CPU 

140 in the subscriber unit 124 is able to authenticate the System Level Overview 

identity of the boot block and OS components that have been 4Q \ system level overview of the operation of an exemplary 

loaded into the computer, and to provide quoting and secure embodiment of the invention is described by reference to 

storage operations based on this identity as briefly described piG. 2. A subscriber computer 200, such as client computer 

next. Full descriptions of various embodiments for the 20 in FIG. 1, is connected to a content provider server 

subscriber unit 124 arc provided in the related application. computer 220, such as remote computer 49, through a 

The CPU 140 has a processor 160 and also can have a 45 wide-area network, such as WAN 52. Processes performed 

cryptographic accelerator 162. The CPU 140 is capable of by the components of the subscriber computer 200 and the 

performing cryptographic functions, such as signing, content provider 220 are illustrated by arrows in FIG. 2. 

encrypting, decrypting, and authenticating, with or without Many of these processes incorporate either public/private 

the accelerator 162 assisting in intensive mathematical com- key pairs, digital signatures, digital certificates, and/or 

putations commonly involved in cryptographic functions. 50 encryption algorithms, or a combination of these standard 

The CPU manufacturer equips the CPU 140 with a pair of cryptographic functions. Such functions are assumed to be 

public and private keys 164 that is unique to the CPU. For provided by the CPU of the subscriber computer in the 

discussion purpose, the CPU's public key is referred to as descriptions that follow, but can be provided by other 

"Kcpi/* and the corresponding private key is referred to as well-known cryptographic mechanisms as will be immedi- 

"Kcpu' 1 "- 0ttlcr physical implementations may include 55 ately understood by one skilled in the art. 

storing the key on an external device to which the main CPU To prevent their content from being stolen or misused, 

has privileged access (where the stored secrets are inacces- content providers will download content only to known 

sible to arbitrary application or operating systems code). The software, and therefore only to subscriber computers that 

private key is never revealed and is used only for the specific can prove that their operating systems will enforce the 

purpose of signing stylized statements, such as when g 0 limitations the provider places on the content. Such a digital 

responding to challenges from a content provider, as is rights management operating system (DRMOS) must load 

discussed below. and execute only OS components that are authenticated as 

The manufacturer also issues a signed certificate 166 respecting digital rights ("trusted"), and must allow access 

testifying that it produced the CPU according to a known to the downloaded content by only similarly trusted appli- 

specification. Generally, the certificate testifies that the 65 cations. 

manufacturer created the key pair 164, placed the key pair The first requirement is met in the exemplary embodiment 

onto the CPU 140, and then destroyed its own knowledge of of the invention by having all trusted operating system-level 
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components digitally signed by their developers or a trusted certificate 210 to determine whether it should establish a 

third -party, with the signature acting as a guarantee that the trust relationship with the DRMOS 205 on the subscriber 

components respect digital rights. The signature is validated computer 200. 

before the component is loaded. The resulting DRMOS is In an alternate exemplary embodiment, the challenge - 

assigned a unique trusted identity, as explained in detail 5 response protocol runs over a secure connection such as SSL 

below, which is recorded in an internal register in the CPU, (Secure Socket Layer) or TLS (Transport Level Security), 

such as SIR 168 in FIG. IB. FIG. 2 illustrates a DRMOS which relies on a session key to encrypt the data transferred 

205, with its identity 206, after it has been loaded into the between the subscriber computer 200 and the content pro- 
CPU 201 of a subscriber computer 200 through such a vider 220, This stops an attacker (such as the legitimate 
loading process 1. 10 owner of the machine) from rebooting the PC into a different 

The second requirement has two aspects. First, trusted °P erati °g ^ lem after the DRMOS has authenticated itself, 

applications must be identified in some fashion, and, second, ° r u » n 5 » different computer on the network for snooping on 

the DRMOS must prevent non-trusted applications from the data destined f° r lhe DRMOS. 

gaining access to the content when it is stored, either If the trust relationship is established, the provider down- 

permanently or temporarily, on the subscriber computer. 15 loads 4 ^ content 221, an access predicate 222, and a 

In the exemplary embodiment shown in FIG. 2, a trusted "^'l 2 * * the DRMOS 205 on the subscriber com- 

application 209 has agreed to operate in accordance with the P„ u, , er m ™ e access 22 ? s P ecifies ^ Properties 

limitations placed on content by a provider. The trusted ' hat an a PP^ation must have in order to process the content 

1- tnn • a * G j at. if u ■ t_. -» 221, such as read-only or minimum/maximum video reso- 

apphcation 209 is identified through a rights manager . . ' ™ J ,. . . - c 

certificate 210. In one embodiment, the rights manager M ^ ™ e acc f P redlci f 222 ^ als f! s P eciflc 

* ha a j * j j •* i J^n * i ■ i applications or families of applications allowed to process 

certificate 210 extends a standard digital certificate, which 4 ^ .. ™~ . . . t . r tL 

... ... g 1. 1 * < * a c *u the content 221. The license 223 places restrictions on the 

mcludes such items as date of pub hcation and name of the L A , r . ... , 

v 4 . , j j- i- * r ** use of the content 221 by an approved application, such as 

application, by adding a list of services, or properties, # . . , t . ' * y . ,™ ' . . 

provided by tihe appHcation, i.e., content type handled, ^ "umber of times the content can be accessed or what 

version of the application, whether it saves content to disk, 25 6 ™u ^^J^t ^ „i u 

etc. For purposes of the exemplary embodiment shown in When DR MOS 205 receives the content 221, the 

FIG. 2, the certificate 210 also identifies the trusted appli- P^cate 222 f d ' h ! llCense 223 \ 11 dele ™ ines 

cation; alternate mechanisms for identifying a trusted appli- th f content should be permanently stored in a 

cation are described later in the methods section. key-secured storage. If so, it requests an application storage 

-„ w „ ™* . , i j c 30 key from the CPU 201. In the present example, the apph- 

P RM0 ^ 205 P r0Vldes key-secured storage for per- J [Qn e k ^ ific [0 (hc lication 209 

manently stored content to prevent unauthorized access * to ^ ^ 22L ^ 221 and the liccnsc 

the content. For temporarily stored content the DRMOS 205 ^ ^ ted ^ tne application storage key and the 

prevents an untrusted I process from reading the memory ^ 222 ^ aUached to ^ e d informa . 

holding the content. These and other safeguards are also 3S ^ , f ^ m fe tQ be stofed on , u aril the 

desenbed in detail below. The permanent and temporary DRMOS 205 places various safeguards around the memory 

storage within subsenber computer 200 are coUectively area h(M ^ M that the cannol be 

represented by device 203, which is illustrated in FIG. 2 as accessed b an ^ nlrns{od application . The generation of 

a disk drive. Such illustration is not intended to limit the lication sto k aad tne m safeguards are 

range of devices that can serve as secured storage for a 4Q de £ cribed ^ detail below 

Each time application 209 wants to access the stored 

Turning now to the remainder of the processes depicted in CQntent 221? it passes its dghts manager certificate 210 and 

FIG. 2, application 209 requests 2 the download of content the appropriate application storage key (action 8) to the 

221 from provider 220. The DRMOS 205 sends a message D RMOS 205. The DRMOS 205 validates the key and 

3 to the provider 220 requesting the content 221. The content 45 compares the manag er certificate 210 against the 

provider 220 transmits a challenge message 4 to the access predicate 222 . Assuming the storage key is authen- 

DRMOS 205 asking for the identity of the CPU 201, the Seated and the rights manager certificate 210 satisfies the 

DRMOS 205, and the application 209. The DRMOS 205 acccss predicatc 222 , thc contcnt 221 and the license 223 are 

transmits a response message 5 containing a certificate 202 decrypled . DRMOS determines if the application's use 

for the CPU 201, its own identity 206, and the rights 50 0 f the content is permitted under the license 223 and allows 

manager certificate 210 for the application 209. access 9 if it is 

The challenge-response process follows the common pro- The system i eve l overview of the operation of an exem- 

tocol for such interchanges, the difference being only in the plary embodiment of the invention has been described in this 

data exchanged between the subscriber computer and the section of the detailed description. A series of processes and 

content provider. In one exemplary embodiment of a suit- 55 data structures on a subscriber computer control the loading 

able challenge-response process described in the related of a digital rights management operating system, identify the 

application titled "System and Method for Authenticating an DRMOS and trusted applications to a content provider, and 

Operating System to a Central Processing Unit, Providing secure content downloaded by the provider to the subscriber 

the CPU/OS with Secure Storage, and Authenticating the computer. While the invention is not limited to any particu- 

CPU/OS to a Third Party," the certificate 202 contains the 60 i ar hardware and software, for sake of clarity only a minimal 

challenge message 3, the identity of the DRMOS 206, the hardware and software configuration necessary to process 

public key of the CPU 201, and data representing all multimedia has been assumed for the subscriber computer, 
software components that are currently loaded and executing 

on the subscriber computer 200. Hie certificate 202 is signed Methods of Exemplary Embodiments of the 

using the private key of the CPU 201. The content provider 65 Invention 

220 examines the CPU certificate 202, the DRMOS identity In the previous section, a system level overview of the 

206, and the properties specified in the rights manager operation of exemplary embodiments of the invention was 
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described. In this section, the particular methods performed untrusted component after the boot process completes, a 

by a subscriber computer, or client, of such exemplary plug- and -play DRMOS must then "renounce" its trusted 

embodiments are described by reference to a series of identity and terminate any executing trusted applications 

flowcharts and operational diagrams. The methods to be (block 323) before loading the component. The determina- 

performed by the client constitute computer programs made 5 U0D *n untrusted component must be loaded can be 

up of computer-executable instructions. Describing the based on a system configuration parameter or on instructions 

methods by reference to flowcharts and operational dia- from the user of me computer. 

grams enables one skilled in the art to develop such pro- Assuming the signature is valid (block 305) and the 
grams including such instructions to carry out the methods component is trusted (block 309), it is loaded (block 311). 
on suitable computerized clients (e.g., on the processor of a 10 ^ trustworthiness of a component can be decided using 
client executing the instructions from computer-readable v ™ cn * ent - In one embodiment only components pro- 
media). Data structures necessary to perform the methods V1 ? ed operating system developer are trusted At the 
are also described in this section. The methods of the content other end of me f de ' m aD t ot ^ er l mb °^ m !^ f com ^' 
provider server computer are described to complete the nents are assumed trustworthy by the DRMOS, leaving the 
understanding of the methods performed by the client. is fiaal deasion to the content provider as described in more 
, - t , , _ , detail below. Still a third alternate embodiment provides that 
Although many of the methods are interrelated, they have onents ^ d b of a xlecl nl]rnber of entities can 
been divided into tour groups to tacUitate understanding. be considered 

as equivalent to components provided bv the 

The boot/load process and various mechanisms for creating DRMOS developer. In this embodiment, the identity of the 

identities for fcfferen ^versions of a ,d.pul nght management fe ^ WDsid(Rd (0 , he 

operating system (DRMOS) are first described. The func- 20 ure „ DRMQS ^ ^ DRMQS deve , ^ 

lions that must be provided by the DRMOS to ensure the con , en( idef decWes whether ^ ^ e P uivalent 

enforcement of the content providers rights arc described * svstcm 

next. The third group consists of methods directed toward „ . ' .1 . ? . . 

providing permanent storage of the content on the subscriber , Furthermore, not all versions of a component may be 

r * r j 1 j j j * *u * , * i< trusted. Because the nghts manager certificate contaias the 

computer once downloaded, and protecting that content 25 . » * 

from unauthorized access. Finally, the identification of version number of the component, it can be used to verify 

. , j*u • u* *t the trust level of a particular version. One embodiment of the 

trusted applications and the nghts management functions are , . r , 4 A . 

described loading process checks a component certification revocation 

' . ' , , , .„ . , list (CRL) to determine whether a component signature has 

Booting/Uading and Identifying the DRMOS ^ been revoked Jhe CRL can be provided by ^ 

Referring first to FIG. 3, a flowchart of a method to be provider or the DRMOS developer. An exemplary embodi- 

performed by a subscriber computer according to an exem- merjt 0 f a CRL is illustrated in FIG. 4. Each entry 401 

plary embodiment of the invention is shown. This method is contains the name of the component 403, the version 405, 

inclusive of the acts required to be taken by the computer to and the signer 407 wnose signature is revoked. The particu- 

boot a DRMOS or to load additional components after the 35 lar CRL used becomes part of the operating system identity 

boot process is complete. Exemplary embodiments of boot usmg a standard hashing function described further below, 

block data structures are described below in conjunction Alternatively, if the rights manager certificates on the 

with MGS. 7A-C. components are short-lived and must be renewed 

Shortly after a computer is turned on or is reset, a small periodically, then a version that is found to be untrustworthy 

program called a boot loader is executed by the CPU (block 40 win not have its certificate renewed. This alternate embodi- 

301). The boot loader loads a boot block for a particular men t requires a secure time source to be available on the 

operating system. Code in the boot block then loads various subscriber computer so the user cannot simply turn back the 

drivers and other software components necessary for the system clock on the subscriber computer. A monotonic 

operating system to function on the computer. The totality of counter in the CPU can serve as this secure time source since 

the boot block and the loaded components make up the 45 j t on iy CO unts up and cannot be reset "back in time." For 

identity of the operating system. example, a monotonic counter that is periodically incre- 

For a DRMOS, that identity can be trusted only if the boot mented while the CPU is active, and that cannot be reset, can 

block and the loaded components are trusted. In the embodi- be used in conjunction with a secure time service, such as a 

ments described herein, all components are signed by a secure Internet time service, to provide a lower bound on the 

trusted source and provided with a rights manager certifi- 50 current time in a trusted manner. Such exemplary use of a 

cate. An exemplary embodiment of the rights manager monotonic counter is described in detail below as part of the 

certificate is described below in conjunction with FIG. 9. functions of the DRMOS. 

The operating system checks the signature of a compo- Once all components are loaded, the operating system 

nent before loading it (block 303). If the signature is valid assumes its identity (block 315). In one embodiment, a 

(block 305), the component has not been compromised by 55 one-way hashing function provided by the CPU is used to 

someone attempting to circumvent the boot process and the create a cryptographic "digest" of all the loaded compo - 

process proceeds to check the level of trust assigned to the nents. The digest becomes the identity for the operating 

component (block 307). If the signature is not valid (or if system and is recorded in an internal register in the CPU. 

there is no signature) but the component must be loaded Alternate methodologies of assigning an identity to the 

(block 319), the operating system will not assume the $o loaded components are equally applicable as long as a 

identity of a DRMOS upon completion of the boot process non-trusted configuration cannot have the same identity as a 

as explained further below. DRMOS. Signing the operating system identity with a 

A plug-and-play operating system provides an environ- private key particular to the type of CPU serves to identify 

ment in which devices and their supporting software com- both the operating system and the processor on which it is 

po nents can be added to the computer during normal opera- 65 executing. 

tion rather than requiring all components be loaded during If all computers were identically configured, a single, 

the boot process. If the device requires the loading of an signed operating system identity would suffice to authenti- 
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cate a particular operating system executing on a particular 
type of CPU. However, computers contain a myriad different 
hardware components, and the corresponding supporting 
software components are frequently updated to add enhance- 
ments and fix problems, resulting in a virtually unlimited 5 
number of operating system identities. Therefore, the con- 
tent provider would have to maintain a registry of each 
subscriber's DRMOS identity or delegate that function to a 
trusted third party. 

The problems attendant on having a vast number of 10 
DRMOS identities can be alleviated in at least three ways. 
First, an identity is generated or assigned for the basic 
configuration of each operating system. Such a basic con- 
figuration includes only components supplied by the oper- 
ating system vendor. The identity is generated (or assigned) 15 
and stored when the basic components have been loaded. 
Different versions of the basic operating system will gener- 
ate (or be assigned) different identities. 

Once the basic configuration of a DRMOS is loaded and 
its trusted identity is stored, subsequent components 20 
required to support the particular hardware configuration 
must be verified and loaded as explained in conjunction with 
FIG. 3. Such additional software components can also 
include updates to the basic components provided by ven- 
dors other than the operating system developer. Each addi- 25 
tional loaded component has an individual identity (such as 
a cryptographic digest) generated/assigned and stored. All 
the identities are uploaded to the content provider when the 
DRMOS identity is requested. Because the basic DRMOS 
and additional components always have the same identities 30 
when executing on a specific type of processor, the content 
provider has only to maintain a list of the identities for the 
combinations of the basic DRMOS and additional compo- 
nents that the provider trusts. Each identity uploaded is then 
checked against the list. 35 

In a second alternate embodiment, the operating system 
maintains a "boot log," containing the identity of the basic 
DRMOS and the identities of the additional OS components 
that have been loaded. The identity is a cryptographic digest 4Q 
of the code for the component, or a well-known name, or any 
other sting that is uniquely associated with the component. 
The CPU also maintains a composite identity register that 
holds a one-way cryptographic function of the boot log. 
Whenever a component is loaded, its identity is appended to 45 
the boot log and folded into the composite identity register, 
such as by setting this register to a secure hash of its old 
value appended with the new component's identity. When- 
ever the CPU certifies the current value of its composite 
identity register, it also verifies that the operating system's 5Q 
boot log has not been tampered with. Because the log is 
indelible, the loaded component cannot erase the record that 
shows it was loaded. 

An alternate exemplary embodiment of the boot log holds 
the entire boot log in the CPU, The DRMOS uses an 55 
instruction provided by the CPU that appends the identity of 
each loaded component to the log. The CPU then signs the 
boot log to attest to its validity and delivers the signed boot 
log to the content provider as the identity for the DRMOS. 

In another alternate embodiment, DRMOS uses a chain of 60 
public and private key pairs newly generated by the CPU to 
create an indelible boot log. The method is shown in FIG. 5 
and an exemplary embodiment of the completed boot log is 
illustrated in FIG. 6. The boot loader generates or obtains a 
first key pair (Kq, Kq -1 ) and records the first key pair in 65 
memory (block 501). The first public key is also saved to 
secure storage in the CPU. The boot loader toads the boot 
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block into memory and records the identity of the boot block 
in the boot log (block 503). Before turning control over to 
the boot block code, the boot loader obtains a second key 
pair (Kj, K a ~ 3 ) (block 505), writes the second public key 
(K a ) to the boot log (block 507), and then signs the boot log 
with the first private key (K^ 1 ) (block 509). The boot loader 
deletes the first private key (Kq -1 ) from its memory (block 
511) and relinquishes control to the boot block. 

The boot block code loads additional components into 
memory, records the identities of those components to the 
boot log (block 515), obtains a third key pair (K^ K^" 1 ) 
(block 505), appends the boot log with the third public key 
(Kj) (block 507), and signs its portion of the boot log with 
the second private key Kj" 1 (block 509). The boot block 
erases the second private key (K t _1 ) (block 511) from 
memory and turns control of the boot process over to the first 
loaded component. Each loaded component that will load 
additional components obtains a new key pair (K„, K„ -1 ) 
and uses the private key of the previous key pair (K^ -1 ) to 
sign its portion of the boot log. The boot process continues 
in this iterative manner through until all components arc 
loaded or, in the case of a plug-and-and play DRMOS, a 
content provider challenge is received (block 513). 

When a non-plug-and-play DRMOS resumes control after 
the final component is loaded, it places a "sentinel" on the 
boot log (block 519) to indicate that the log is complete and 
to prevent a loaded component from deleting entire lines of 
the log. The characteristics of the sentinel are that is a 
known, unique value that is signed using the last private key 
(K,," 1 ), In the present embodiment, the sentinel is a signed 
zero entry. The DRMOS deletes the last private key and all 
public keys from memory after creating the sentinel. 

Because a plug-and-play DRMOS cannot arbitrarily 
declare that all components arc loaded at the end of the boot 
process, the DRMOS cannot add a sentinel to the end of the 
boot log at that time. Instead, the DRMOS attests to its most 
recent public key K„ as well as its first public key Kq to 
certify the contents of the boot log when challenged. 

Using a chain of key pairs 606, 607, as shown in FIG. 6, 
guarantees the boot log reflects the loaded components. 
Each public key in a log section is used to authenticate the 
signature on the next section. The first public key remains in 
memory to authenticate the signature on the boot block 
section of the log. While each set of components is free to 
load more components, a component cannot change the 
recording of its identity in a previous portion of the log 
because doing so would cause the validity check on the 
corresponding signature to fail. Similarly, a section in the 
middle of the log cannot be deleted because that would break 
the chain of keys. Deleting multiple sections of the log 
through to the end also breaks the chain. In this case, 
attempting to insert a new sentinel in an effort to make the 
log appear unaltered will fail because the private key nec- 
essary to add the sentinel is no longer available. Finally, the 
entire boot log cannot be replaced since the signature on the 
boot block section of the log would not be validated by the 
first public key. 

Turning now to the boot block, one exemplary embodi- 
ment suitable for use with a digital rights management 
operating system is shown in FIG. 7 A. The boot code 701 is 
signed (signature 703) by the developer of the DRMOS 
using its private key. The corresponding public key 705 of 
the developer is attached to the boot block 700. In an 
alternate embodiment, the public key 705 is not attached to 
the boot block 700, but instead is persistently stored in an 
internal register in the CPU. The public key 705 is used to 
validate the signature 703. 
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If the DRMOS developer's private key used to sign the An example of one kind of procedure that must be 

boot block is compromised, the key pair must be changed prohibited is loading a kernel debugger because it would 

and thus all boot blocks must be reissued to subscriber allow the user to make a copy of the content loaded in 

computers. FIG. 7B illustrates an alternate embodiment of a memory. If the user of the subscriber computer attempts to 

boot block that ameliorates this problem. Boot block 710 $ load a kernel debugger into memory, the DRMOS can either 

comprises a basic boot section 711 and an intermediate boot 1) refuse to load the debugger, or 2renounce its trusted 

section 713. The basic boot section 711 contains boot code identity and terminate the trusted application that was 

715 that validates and loads the intermediate boot section accessing the content before loading the debugger. In the 

713 and components not provided by the DRMOS devel- latter case, the memory must also be purged of the content 

open The intermediate boot section 713 contains boot code before the debugger is loaded. The choice of action can be 

717 that validates and loads components from the DRMOS pre-determined or chosen by the user when the user attempts 

developer. The intermediate boot section 713 is signed with to load the kernel debugger. One of skill in the art will 

a special boot block private key. The basic boot code 715 immediately identify other types of programs that will need 

uses a corresponding boot block public key 719 stored in the to be treated in the same manner as a kernel debugger, 

basic boot section 711 to validate the intermediate boot Virtual memory operating systems maintain a page file 

section 713. Components 727 from the DRMOS developer that holds sections of program code and data that are not 

are signed 729 with the developer's standard private key and currently active. Under normal circumstances, the contents 

the intermediate boot section 713 uses the DRMOS devel- of the page file are accessible by the user of the computer, 

oper's standard public key 721 to validate those compo- either by running a privileged program or by booting another 

nents. ^ operating system that allows inspection of the disk. 

If the standard private key used to sign components is Therefore, a DRMOS must either protect content stored on 

compromised, the developer creates a new standard key pair the page file or must not page content and similar protected 

and provides a replacement intermediate boot block 713 information at all. 

containing the new standard public key. Replacement com- Protecting content on the page file can be accomplished in 

ponents signed with the new standard private key are also 25 at least three ways. First, the DRMOS can prohibit all "raw" 

issued. Because the special boot block private key is used for access to page file device when a trusted application is 

few, if any, other purposes than signing boot blocks, it is less running. Second, the DRMOS can terminate all trusted 

likely to be compromised and replacement of the basic boot applications and erase the page file before allowing such 

section 711 will rarely be necessary. access. Third, the DRMOS can encrypt the content and 

In FIG. 7C, an alternate embodiment of the single section 30 similar protected information before writing it to the page 

boot block 730 also uses a special boot block key pair. The file. 

boot block 730 contains the special boot block, or master, Often, a DRMOS must allow the user to perform certain 

public key 733. The master private key is used to certify standard functions but prohibit other, related functions. The 

ephemeral keys that are valid for a short period of time. DRMOS can assign the user permissions based on the 

Certificates signed 737 by the master private key attest to the 35 granularity of the normally permitted function. For example, 

validity of the ephemeral keys. A component is signed with the DRMOS can allow the user to delete an entire content 

one of the ephemeral private keys and the corresponding file but not a portion of it. Another example is that the 

certificate 739 is attached. The boot block determines that DRMOS can allow the user to terminate all the threads of 

the certificate on the component is valid using the master execution for a trusted application but not just a single 

public key. When the ephemeral key expires, the DRMOS 40 thread. 

developer issues replacement components. As with the two- Finally, a DRMOS must protect the trusted application 

section boot block shown in FIG. 7B, the master private key itself from tampering. The DRMOS must not allow other 

is only used to sign the certificates for the ephemeral keys so processes to attach to the process executing the trusted 

it is less likely to be compromised. Because the ephemeral application. When the trusted application is loaded into 

keys are valid for only a short duration, public release of a 45 memory, the DRMOS must prevent any other process from 

private ephemeral key has limited impact. reading from, or writing to, the sections of memory allocated 

Functions of a DRMOS to the trusted application without the explicit permission or 

As described above, components may be valid only until cooperation of the trusted application, 

a specified date and time, and content may also be licensed Key-based Secure Storage 

only until a certain date and time. The monotonic counter 50 In order to protect content permanently stored on the 

described earlier can also be used to ensure that the com- subscriber computer, the DRMOS must provide a secure 

puter's clock cannot be set backwards to allow the replace- storage space. In essence, the DRMOS must securely store 

ment of a trusted component by an earlier, now untrusted private keys or session keys for use with encrypted content, 

version. The DRMOS connects on a regular basis to a trusted or provide some other mechanism for keeping these keys 

time server and presents the value of its monotonic counter, 55 secret from other OSs or system level software. These keys 

whereupon the trusted time server returns a certificate bind- can be used for the secure storage and retrieval of protected 

ing that value to the current time. If the monotonic counter information. In the exemplary embodiments described in 

is updated periodically, such as every hour that the DRMOS this section, the information to be stored in a protected 

is ruling, then the monotonic counter in conjunction with the format is encrypted using one of a set of keys that may be 

most recent time certificate can serve as a useful approxi- 60 generated by a function 800 (FIG. 8) provided by the CPU. 

mation to a trusted clock. The storage key generation process is tightly coupled to the 

A DRMOS must also protect the content once it is loaded DRMOS so that the same key cannot be generated by the 

into the client computer's memory by a trusted application. CPU for an unrelated operating system, or by any software 

In particular, the DRMOS must prohibit the use of certain on another computer. Three types of storage keys are envi- 

types of programs and refrain from performing certain 65 sioned as illustrated in FIG. 8: an OS storage key 801, an 

common operating system procedures when content is in application storage key 811, and a user storage key 821. 

memory. Each key is specific to the entity that requests it. 
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Beginning with the OS storage key 801, the DRMOS second hashed seed 833 is unique to the user. The second 

passes a "seed" 803 as an operand of a key-generation hashed seed 833 is passed to the CPU, which returns the user 

instruction ("Generate Key") 805 to the CPU and receives an storage key 821. As described above, only the same user will 

OS storage key based on the seed 803 and the identity of the be able to access data encrypted with the storage key 821 

DRMOS. The CPU will always return the same OS storage 5 when the DRMOS that generated the key is executing, 

key 801 when the same seed 803 is provided by the same Analogously, the keyed hash routine 829 guarantees that the 

DRMOS but will return a different OS storage key if the user storage key will not duplicate either an OS storage key 

same seed 803 is provided by an unrelated operating system. or an application storage key based on the same seed. Such 

Because an unrelated operating system cannot get the same a facility is used when downloaded content can be accessed 

key 801, it cannot read any data encrypted by the DRMOS. only by a particular user. Moreover, if downloaded content 

In an alternate embodiment, only a single operating is to be accessed only by a particular user and by a particular 

system storage key is used by the DRMOS as described application, the secret to be stored may be divided into parts, 

below. Therefore, in this embodiment only the identity of the with one part protected by an application -specific key and 

DRMOS is factored into the key generation function 800 the other part protected by a user-specific key. 

and the seed 803 is not necessary. 15 Once the data is encrypted using the storage keys, there 

An application storage key 811 is generated when an must be a way to recover the keys when the DRMOS 
application calls an operating system instruction identity changes (as when the operating system is upgraded 
("GenerateApplKey") 815 using a seed 813. The DRMOS to an incompatible version or an unrelated operating system 
passes the seed 813 through an application-specific one-way is installed) or the computer hardware fails. In the exemplary 
hash function 817 to produce a hashed seed 819. The hashed 2 o embodiments described here, the keys are stored off-site in 
seed 81 9 is then passed to the CPU through the GenerateKey a "key vault" provided by a trusted third party. In one 
instruction described above. The resulting application stor- embodiment, the DRMOS contains the IP addresses of the 
age key 811 is returned to the application for use. Because key vault providers and the user decides which to use. In 
the GenerateKey function uses the operating system's another embodiment, the content provider designates a 
identity, the same application executing under an unrelated 2 s specific key vault and the DRMOS enforces the designation, 
operating system cannot get the same key, and therefore In either embodiment, when the user requests the restoration 
cannot access the encrypted data, even if it requests the key of the storage keys, the key vault provider must perform a 
using the same seed 813. Similarly, an unrelated application certain amount of validation before performing the down- 
using the same seed 813 gets a different key because the load. The validation process can include such actions as 
DRMOS passes the seed 813 through a different hash 30 recording the identity of the original operating system (or 
algorithm for each application. computer) in a revocation list, checking the frequency of the 

In an alternate embodiment, the operating system stores requests, and requiring a credit card number before down- 
decryption keys for applications using its own identity; the loading the storage keys, 
applications call the operating system to retrieve application Rights Management 

keys. This also provides a way for an application to allow 35 Most operating systems do not directly process media 

other applications access to its key and therefore to the content, such as video or audio. That function is usually 

content encrypted by the key. Instead of creating a secret available through special application programs. Therefore, a 

using a seed 813, the application passes in the access content provider must not only trust the opera ting system but 

predicate for the content. The access predicate designates must also trust the application that will process the content, 

values that must be present in the rights manager certificate 40 Content also can be accompanied by a predicate stating 

for an application wishing access to the content. An exem- which applications are to be trusted to access that content, 

plary embodiment for an access predicate is shown in FIG. and this statement can include a list of generic properties that 

9 and described in detail in the following section. The implicitly define a set of applications. Further associating a 

DRMOS supplies the seed 813 that is required to generate rights manager certificate with the application provides 

the application specific key and passes the seed 813 through 45 identification of the application and certification of its prop- 

a generic one-way hash. The DRMOS encrypts the seed 813 erties. This allows the content provider to determine if the 

and the access predicate using an OS storage key and application fulfills the requirements of the content provider 

associates the encrypted access predicate with the encrypted before downloading content, and also allows the operating 

seed. When any application requests access to a key pro- system to restrict future access to only the appropriate 

tected by an access predicate, the DRMOS compares the 50 applications. 

criteria ill the access predicate against the rights manager One exemplary embodiment of a rights manager certifi- 

certificate of the requesting application. An application that cation is shown in FIG. 9. A list of application properties 903 

meets the criteria is given access to the seed 813 and is appended to the digital certificate fields 901 standard in 

therefore to the application storage key. Because the seed some digital certificate format such as X.509. The certificate 

813 is encrypted using an OS storage key, an application that 55 names the application. Each entry 905 in the list 903 defines 

is running under an unrelated operating system will be a property 906 of the application, along with optional 

unable to gain access to the encrypted data because the arguments 907. For example, one property might be that the 

unrelated operating system cannot decrypt the seed 813. application cannot be used to copy content. Another 

Finally, a particular user can request a key that is based on example of a property is one that specifies that the applica- 

a user identity assigned by the DRMOS or another facility 60 tion can be used to copy content, but only in analog form at 

that guarantees a unique identity for each user. The user 480P resolution. Yet another example of a property is one 

supplies a seed 823 in a "GenerateUserKey" call 825. The that specifies that the application can be used to copy 

operating system passes the seed 823 through a one-way content, but only if explicitly allowed by an accompanying 

hash 828, and then passes the resulting first hashed seed 827 license. Additional examples include the right to store an 

through a keyed hash routine 829 to generate a second 65 encrypted copy of the content and to restrict such storage to 

hashed seed 833. The operating system factors the user only certain, acceptable peripheral devices. The property 

identity 831 into the keyed hash routine 829 so that the 906 can also be used to specify acceptable helper 
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applications, such as third-party multimedia processing trusted application when it redistributes the content. The 

stacks or other libraries, to be used in conjunction with the sublicense is structurally identical to the license data struc- 

application named in the certificate. The certificate is signed ture 1100 although the content of the fields differs, 

by an operating system vendor, content provider, or third Additional licensing restrictions will be readily apparent 

party, certifying the properties of the application. 5 to one skilled in the art and are contemplated as within the 

Because the content provider must trust the DRMOS and scope of the invention, 

application to protect the content from misuse once The license 1100 is stored with the content on secured 

downloaded, the content provider attaches an access predi- storage. In one embodiment, the required properties ACL 

cate to the content. This access predicate can also include a 1000 is also stored with the license 1100 and the content. In 

license to the content. The basic functions of both the access 10 an alternate embodiment, the ACL 1000 is secured sepa- 

predicate and the license, which were described in the rately and controls access to the storage key for the content 

system overview, are explained in detail next. as described above. 

In one embodiment, the access predicate takes the form of In the embodiments described above, the DRMOS is 
a required properties access control list (ACL) as shown in responsible for checking the required properties ACL and for 
FIG. 10. The required properties ACL 1000 contains a basic 15 enforcing the licensing restrictions. By providing the vali- 
trust level field 1001, which specifies the minimum rights dation functions in the DRMOS, the functions are central- 
management functions that must be provided by any appli- ized and can be utilized by any process. In an alternate 
cation wishing to process the content. These minimum embodiment, the validation functions concerning the appli- 
f unctions can be established by a trade association, such as cation are coded directly into the trusted applications pro- 
the MPAA (Motion Picture Association of America), or by 20 grams. A similar effect is achieved in yet another alternate 
the DRMOS vendor. A unique identifier is used to reference embodiment that places the application validation functions 
a list of the minimum functions. The minimum functions list in a library that is incorporated into the trusted applications, 
can include CPU, DRMOS, and application specific require- One of skill in the art will immediately perceive that 
ments. ^ certain rights are more easily enforced at the DRMOS level, 

The required properties ACL 1000 can also contain one or such as the right for a certain application to access a key or 

more extended trust level fields 1003. The extended trust other content, or the ability to open a file a limited number 

level fields 1003 contains identifiers that specify additional of times, while other types of rights are best enforced by the 

rights management function that must be provided by the application itself. Since the DRMOS enforces the restriction 

subscriber computer. For example, a required properties 3Q that only explicitly stated applications can access restricted 

ACL can require that only a certain version of a particular content, the application can be trusted to enforce the addi- 

application be allowed access to the content. The required tional restrictions. Alternate embodiments in which the 

properties ACL 1000 is compared against the certificates for enforcement of certain rights is allocated to the DRMOS and 

the CPU, the DRMOS, and the application starting at the the enforcement of others to the application is therefore 

hardware level, i.e., CPU, DRMOS, application name, 35 contemplated as within the scope of the invention, 

version, and specific properties for the application. One of As described above in conjunction with FIG. 2, the 

skill in the art will readily recognize that the required content provider 220 delivers content to the subscriber 

properties ACL 1000 can require that all properties must be computer 200 after trust is established by transmitting the 

present, or at cast one of the properties, or some specified appropriate certificates/identities for the CPU, the DRMOS, 

subset. 4Q and the application to the provider. The content can be 

The content license (FIG. U) imposes additional restric- explicitly encrypted by the content provider for this combi- 
tions on what kind of processing can be performed on the nation of CPU, DRMOS, and application, as described 
content once an application has access to the content. As above, or, if the content is sent over a secured link (with, for 
described briefly above, the license data structure 1100 can example, Secure Socket Layer services), the content pro- 
limit the number of times the content can be accessed (usage 45 vider can encrypt the content using the session key for the 
counter 1101), determine what use can be made of the secure link. In the latter embodiment, the DRMOS writes the 
content (derivation rights 1103), such as extracting still shots encrypted content to permanent storage and uses one of the 
from a video, or building an endless loop recording from an storage keys generated by the CPU to securely store the 
audio file, or a time-based expiration counter 1105. session key for later use. Alternately, the content provider 

The license can also specify whether or not a trusted 50 can choose not t0 encrypt the content if it is transmitted to 

application is permitted to validate other client computers the application in a secure fashion, in which case the 

and share the content with them (sublicense rights 1107), in application performs the encryption if it stores a persistent 

effect having the subscriber computer act as a secondary C0 P V °^ me content. 

content provider. The sublicense rights 1107 can impose The particular methods performed by a subscriber corn- 
more restrictive rights on re -distributed content than those 55 puter of an exemplary embodiment of the invention have 
specified in a license for content downloaded directly from been described. The methods performed by the subscriber 
the original content provider. For example, the license 1100 computer have been shown by reference to flowcharts, 
on a song purchased directly from the music publisher can operational diagrams, and data structures. Methods per- 
permil a song to be freely re-played while the sublicense formed by the content provider have also been described, 
rights 1107 require a limit on the number of times the same 60 

song can be re-played when re-distributed. To enforce the Conclusion 

sublicense rights 1107, in one embodiment, the trusted A digital rights management system has been described 

application modifies the original license 1100 to specify the whereby certain cryptographic secrets are reliably associ- 

addi tional restrictions and downloads the modified license ated with a particular digital rights management operating 

with the re-distributed content. In an alternate embodiment, 65 system or family of operating systems running on a particu- 

the original content provider downloads a sublicense along lar general -purpose computer. The operating system uses 

with the content and that sublicense is re-distributed by the these secrets to authenticate itself to a third party, to receive 
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encrypted content or information, to store this content or 
information securely, and to retrieve it later. No unrelated 
operating system or other software running on the same 
computer can obtain these secrets and perform these actions, 
nor can any operating system or other software running on 5 
any other computer. By using these cryptographic secrets, 
the digital rights management operating system can recur- 
sively provide derived cryptographic secrets for the same 
uses by applications running on tie same operating system 
on the same computer. 10 

Although specific embodiments have been illustrated and 
described herein, it will be appreciated by those of ordinary 
skill in the art that any arrangement that is calculated to 
achieve the same purpose may be substituted for the specific 
embodiments shown. This application is intended to cover 15 
any adaptations or variations of the present invention. 

For example, those of ordinary skill in the art will 
appreciate that various combination of the exemplary 
embodiments are applicable to solve the digital rights man- 
agement problem depending on the exact computing envi- 20 
ronment. Furthermore, those of ordinary skill in the art will 
recognize that the invention can be practiced on a large scale 
although illustrated herein with only a single subscriber and 
content provider. 

The terminology used in this application with respect to is 
meant to include all hardware and software configuration 
and all networked environments. Therefore, it is manifestly 
intended that this invention be limited only by the following 
claims and equivalents thereof. 

We claim: 

1. A computerized method for loading components in an 
operating system comprising: 

verifying a source for each component before the com- 
ponent is loaded; 35 

establishing a trust level for each component before the 
component is loaded; 

loading each component if the source of the component is 
trusted and the trust level of the component satisfies 
trust criteria; and 40 

generating a trusted identity for the operating system 
when specific components have been loaded, 

2. The computerized method of claim 1, further compris- 
ing: 

loading a component if the source of the component is 45 
untrusted; and 

generating a non-trusted identity for the operating system. 

3. The computerized method of claim 1, further compris- 
ing: 

loading a component if the trust level for the component 

does not satisfy the trust criteria; and 
generating a non-trusted identity for the operating system. 

4. The computerized method of claim 1, further compris- 
ing: 55 

loading a component if the trust level for the component 

does not satisfy the trust criteria; and 
generating an identity unrelated to the trusted identity for 

the operating system. 

5. The computerized method of claim 1, wherein the trust 60 
criteria are based on a digital signature associated with the 
component. 

6. The computerized method of claim 1, wherein the trust 
criteria are based on a list of trusted components. 

7. The computerized method of claim 6, wherein the list 65 
of trusted components comprises a plurality of digests for 
trusted components. 
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8. The computerized method of claim 1, wherein the trust 
criteria are based on the source of the component. 

9. The computerized method of claim 1, wherein the trust 
level is different for different versions of a component. 

10. The computerized method of claim 9, wherein the 
trust criteria is satisfied if the version of the component to be 
loaded is not signed by a revoked digital signature listed in 
a certification revocation list. 

11 . The computerized method of claim 1, wherein the 
trusted identity is generated from the loaded components 
using a one-way hash function. 

12. The computerized method of claim 1, wherein the 
specific components comprise base components. 

13. The computerized method of claim 1, further com- 
prising: 

generating a trusted identity for each component loaded 
after the trusted identity for the operating system has 
been generated. 

14. The computerized method of claim 1, further com- 
prising; 

recording the loading of the components in a boot log. 

15. The computerized method of claim 14, wherein the 
boot log is maintained by a central processing unit, wherein 
the central processing unit is operable for certifying a 
current value for the boot log. 

16. The computerized method of claim 14, wherein a 
secure hash of the boot log is maintained by central pro- 
cessing unit, wherein the central processing unit is operable 
for certifying a current value for the boot log. 

17. The computerized method of claim 14, wherein 
recording the loading of the components in the boot log 
comprises: 

obtaining a first private key and a corresponding first 
public key; 

storing the first public key in a secure location; and 
for each one of a plurality of component subsets, per- 
forming a signing loop until all component subsets 
have been signed, the signing loop comprising: 
recording the loading of the component subset in the boot 
log; 

obtaining a new private key and a corresponding new 
public key; 

recording the new public key in the boot log; 

digitally signing the boot log with the immediately prior 

private key; and 
deleting the immediately prior private key. 

18. The computerized method of claim 14, further com- 
prising: 

recording a sentinel to the boot log, wherein the sentinel 
is a p re-determined value signed with the new private 
key; and 

deleting the new private key. 

19. The computerized method of claim 14, further com- 
prising: 

attesting to the new public key and the first public key to 
authenticate the operating system. 

20. The computerized method of claim 1, wherein one of 
the components is a boot block. 

21. The computerized method of claim 1, wherein the 
elements are performed in the order recited. 

22. A computer-readable medium having stored thereon a 
boot block data structure comprising: 

a certificate entry containing data representing a certifi- 
cate that identifies a digital rights management system; 

a boot code entry containing data representing computer- 
executable instructions for booting the digital rights 
management system identified by the certificate entry; 
and 
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a boot block signature entry containing data representing 
a source that provided the computer-executable instruc- 
tions in the boot code entry, wherein the data in the boot 
block signature entry is verified using the data in the 
certificate entry. 5 

23. The computer- readable medium of claim 22, further 
comprising: 

a boot block public key entry containing data representing 
a special public key for the source; 

an intermediate boot code entry containing data rep re- 10 
senting additional computer-executable instructions for 
booting the digital rights management system identified 
by the certificate entry; 

a special signature entry containing data representing the 5 
source that provided the computer-executable instruc- 
tions in the boot code entry, wherein the data in the 
special signature entry is verified using the data in the 
boot block public key entry; and, a standard public key 
entry containing data representing a standard public 2Q 
key for the source. 

24. A computer system comprising: 
a processing unit; 

a system memory coupled to the processing unit through 
a system bus; 25 

a computer- readable medium coupled to the processing 
unit through a system bus; and 

an operating system boot block executed from the 
computer-readable medium by the processing unit, 
wherein the boot block causes the processing unit to 30 
validate subsequent components to be loaded by the 
boot block, and to generate an identity for the operating 
system based on the loaded components. 



25. The computer system of claim 24, wherein the boot 
block causes the processing unit to validate a subsequent 
component by checking a signature on the component. 

26. The computer system of claim 25, wherein the boot 
block causes the processing unit to validate a subsequent 
component by further determining a trust level for the 
component. 

27. The computer system of claim 24, wherein the boot 
block causes the processing unit to load only subsequent 
components that are validated. 

28. The computer system of claim 24, wherein the boot 
block causes the processing unit to generate an identity that 
is trusted when only validated components are loaded. 

29. The computer system of claim 26, further comprising: 
a loaded component executing block executed from the 

computer-readable medium by the processing unit, 
wherein the loaded component causes the processing 
unit to validate subsequent components to be loaded by 
the loaded component. 

30. The computer system of claim 24, further comprising: 
a boot log facility executed from the computer-readable 

medium by the processing unit, wherein the boot log 
facility causes the processing unit to record an identity 
for each component loaded in a boot log. 

31. The computer system of claim 24, wherein the boot 
log facility further causes the processing unit to generate a 
plurality of public and private key pairs, to record each 
public key in a separate portion of the boot log and to sign 
each portion of the boot log with a private key. 
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